The present invention relates generally to financial transactions, particularly to customers requesting financial transactions with merchants, and more particularly to financial transactions conducted with a financial institution portable payment device issued by a financial institution, such as a credit card that, that may be used both in a retail transaction and in a transit fare transaction.
Portable payment devices can take many forms and are used in a great variety of financial transactions. The portable payment devices can comprise, for example, smart cards, payment tokens, credit cards, debit cards, stored value cards, pre-paid cards contactless cards, cellular telephones, Personal Digital Assistant (PDA) devices, key fobs, or smart cards. The financial transactions can involve, for example, retail purchases, transit fares, access to venue fares, etc. In all such transactions, the portable payment device users (consumers) are concerned with convenience and the merchants with whom they deal are concerned with ease of transacting with their customer-consumers.
Preferably, financial institution portable payment devices issued by a financial institution (FIPPD) are used in an on-line fashion (e.g., a point of service that is connected to a payment processing system during a transaction). The information from the FIPPD may be transmitted on-line to an issuer during a retail payment transaction for purposes of authorizing the use of the FIPPD for that transaction. The issuer may review parameters of the transaction such as transaction amount, credit history, card authenticity, and other factors when determining whether or not to authorize or decline the transaction.
However, some merchant transactions are not on-line such that FIPPD authentication and verification schemes are not readily accommodated. For example, the ability to go on-line in a transit environment such as a subway or bus system, or a venue access environment such as a stadium or concert hall, may be problematic because of the lack of real time communication and lack of network systems for such environments. This is due in part to the need in such environments to process a transaction within about 300 ms, a transit system industry standard, and thereby allow 30 to 45 patrons per minute access into a facility of the transit system such as a subway or a bus. Moreover, a bus on an over-the-road bus route may not have wireless or other communication systems to allow any real-time dialogue with any other systems outside of the bus, such as for on-line fare assessment or on-line admission ticket/voucher/card authorization. Therefore this absence of network connectivity in a transit environment presents a difficulty whenever an on-line authentication of the consumer's means of access, such as an admission ticket, voucher, or access card, is necessary in order to determine whether, for instance, the consumer is entitled to access and has sufficient funds to cover the cost of the desired transaction (fare for riding on the transit system).
Moreover, in a transit environment, the value of the transit fare may not be known at the time of requested access. A fare calculation may depend upon the actual travel distance, direction of travel, station entry and exit locations, mode of travel (subway, bus, water taxi), consumer category (student, senior), and/or times of use (peak, off-peak). Such parameters may be unknown prior to rendering the service. As such, the transit fare payment and collection process cannot be performed effectively using a conventional on-line authentication and approval process.
Traditionally, transit fare calculation and collection have occurred in a closed system. In a closed system, the transit company may issue its own transit portable payment device, such as a read/write smart card, wherein the transit portable payment device carries the necessary credentials and data to allow completion of a transaction at the fare device itself (turnstile, fare box, or other Point of Service). In this case, there is no additional processing required for fare determination at the time of the transaction outside of the interaction between the card and the fare device. Rather, the card is authenticated and read by the fare device, logic is performed by the fare device to apply transit system fare policy, and the card is updated (rewritten) to finalize the transaction details including a deduction of any stored value for the cost of fare. The fare device may additionally query a white list, a positive list, a hot list, a negative list and/or a black list utilizing the card number, for example, to determine whether the transaction will be completed and the cardholder will be allowed access into a facility of the transit system such as a subway terminal or bus passenger compartment.
The closed transit system, however, has its drawbacks. In a closed transit system, the transit portable payment device and transit readers at each station or route must be able to perform fare computations based on data stored and retrieved from a rider's access card, and subsequent card terminals/readers must be able to access data written to the rider's access card at previous stations. This requirement places a significant processing burden on the transit system terminals and/or fare processing systems and increases the cost of implementing the infrastructure for such systems. As fare rates and other relevant information generally change over time, this also increases the demands placed upon such systems for maintenance of accuracy.
Moreover, one transit portable payment device may not be compatible with all of the fare devices within a rider's travel plan. This can become a significant problem if a consumer wishes to utilize more than one transit system during a day's commute, such as by using multiple transit agencies or venues within a single geographical area that provide ridership both in and among different jurisdictions, cities or locations.
The present transit environment presents several challenges, including:                A common necessity that there can be only one transit portable payment device for each transit agency or group of cooperating agencies that cannot be used for other such agencies or groups;        The desire to accommodate transit system user's transaction speed expectations while minimizing risk to the transit agency for collecting payment for services rendered; and        When a portable payment device is ‘read-only,’ not having write capabilities at the Point of Service, the Portable Payment devices cannot store the rider's transit chronology data—thus making the rider's fare calculations somewhat difficult with such devices. With such off-line transactions, a list (i.e., a white list of eligible cards or a negative list of rejected cards based on the unique card number) stored at each transit fare device is the primary mechanism to deter fraud. This is sub-optimal since the negative list would presumably grow unbounded as more FIPPD are issued.        
In addition to the transit system rider's desire for a fast transaction speed when accessing a transit system facility, there are security and other risks associated with the use of a FIPPD that is designed for on-line authorization when it is otherwise used in an off-line transaction. These risks include, but are not limited to:                Authentication/Fraud: the lack of FIPPD authentication in real time creates a high potential for fraud through counterfeiting techniques;        Fare Cost Calculation: where the cost of a transit transaction is dependent upon the immediate rider history for the card (entry/exit/length of travel, transfers, etc.), the rider's transit fare cannot be calculated at each gate or fare box because the rider's immediate history of travel cannot be stored, written or resident on conventional FIPPDs;        Data Security/Storage: protection of consumer data in a transit fare system may prove difficult. Tracking data in the form of a primary account number (PAN) for a FIPPD would require the transit system to collect and store this data securely, which is not something transit fare systems commonly do presently. If implemented, this requirement presents added cost and security concerns to both the transit system and its riders; and        
What is needed in the art is the payment and collection of transactions utilizing a FIDDP device within the above environments, including access fares to transit systems and venues, that overcome the challenges and disadvantages of the prior art.